品質メトリクス

開発したシステムは品質が保証されたものでなければなりません。
そのために、ドキュメントをレビューしたり、プログラムをテストしたりしますが、いつまでレビューをしたらいいのか、どのくらいテストをしたらいいのか、また、検出された不具合の件数は妥当なのか、といったことがわからないままでは、品質を評価することはできません。

客観的に品質を評価するためには、判定をするためのモノサシが必要です。それが、品質指標(メトリクス)です。

メトリクス

メトリクスは、最近になって評価基準といったような意味で用いられるようになった英語で、日本語訳としては指標とするのが一般的なようです。
品質メトリクスとは、品質を評価するための基準ということになります。

システム開発における品質メトリクスは、システム規模の大小によって指標値はスライドするものと考えられ、システム規模を表す数値に一定の係数を与えて求めるスタイルです。

システム開発は、発注者のシステム化に対する要求を、プログラムの集合体であるシステムによって実現させる行動です。

システム化要求に基づきプログラムを作成する必要がありますが、それを定義し指示する文書が設計書、あるいは仕様書と呼ばれるものとなります。したがって設計書(仕様書)の品質は高いものでなければなりません。

次に、作成されたプログラムはシステムに対する要求を実現できていなければ価値を持ちませんので、実際に動作して確認をする必要があります。
そして、発注者に納品されるシステムは、個々のプログラムの集合体となりますので、プログラムが結合された状態での動作検証も求められます。

システム化要求　⇒　設計書(仕様書)　⇒　プログラム　⇒　システム

【レビュー】
「システム化要求をプログラムとして実現するための設計書(仕様書)が的確に作成されているか」文書をチェックする作業

【テスト】
「作成されたプログラムがシステム化要求を実現できているか」プログラムをチェックする作業
「プログラムの集合体としてのシステムがシステム化要求を実現できているか」システムをチェックする作業

品質メトリクスには、レビュー＝作成された文書の品質評価と、テスト＝作成されたプログラム(システム)の品質評価、という２つの視点があるということになります。

レビュー品質メトリクス

設計工程において作成された文書の品質を評価するための指標です。
文書の品質を確認する方法としては、その作業工程で作成される(アウトプットされる)文書が、作業を行なうための前提条件となる(インプットとなる)文書の記述内容を、的確に反映しており、かつ逸脱していないことを検証することとなります。

文書をチェックする作業においても、テスト仕様書と同等のレビュー仕様書を事前に作成することは可能ですが、レビュー仕様書を作成するタイミングで仕様書のブラッシュアップができてしまうため、無価値な作業と考えられています。

そこで、文書のレビュー作業では、どのくらい時間をかけて文書をチェックしたかを品質を測る尺度としています。
また、レビューにより検出された不具合(記述モレやミス)摘出数も品質を評価する指標としています。

レビュー密度

システム規模に応じた、文書をチェックするために費やした時間をレビュー密度としています。

あまりにも短い時間しかレビューをしていないと見落としが発生する危険性があり、また完成度が高い文書に対して必要以上にレビューをしても時間の浪費にしかならないということから、適正なレビュー時間を指標として用意しておくものです。

レビュー誤り指摘率(検出率)

システム規模に応じた、レビューにより指摘された設計上の不具合件数をレビュー誤り指摘率といいます。

システム規模ではなく、文書ボリューム(ページ数)をベースにする場合もあります。文書ボリューム自体がシステム規模に比例して増減するものと考えると、システム規模当たりの誤り件数でも問題はないといえます。

その他：レビュー実施率

全作成文書中、レビューを実施した文書の割合を示すものですが、これはプロダクト(成果物)の品質ではなく、プロセスの品質を表すもので、作業の進捗状況を確認するための指標といえます。

テスト品質メトリクス

試験工程におけるプログラム(またプログラムの集合体としてのシステム)の品質を評価するための指標です。

テストについては、テスト実施時間ではなくテスト実施項目数でテスト品質を評価します。
そのため、テストを実行する前にテスト項目を挙げたテスト仕様書を作成することになります。

そして、テスト内容が適切であるかを確認する作業として、テスト仕様書の文書レビューも行ないます。テスト品質の評価としては、テスト作業自体の品質(テスト工程品質)も含める必要があると考えてください。

試験密度

システム規模に応じた、テスト項目数を試験密度とします。

テスト項目は、操作者の一つの振舞い単位にカウントします。あるボタンを押下した時に２つの項目が出力される場合のテスト項目は２ではなく１です。プログラムの振舞いとしては、２つの項目が両方とも仕様通りに出力されることが正しい結果といえます。

テスト誤り検出率(指摘率)

システム規模に応じた、テストにより検出されたプログラム製作上の不具合件数をテスト誤り検出率といいます。

テストで検出される誤りには、プログラム製作時の誤りの他、設計(仕様書作成)時の誤りも含まれます。また、テスト仕様書の誤りも考えられます。
誤り検出率を、設計を起因とする分・プログラム製作での発生分・その他という形で管理する場合もあります。

誤り件数重複分

誤りには、同じ要因により発生した誤りというものがあります。
特にプログラムレベルになると、プログラム仕様書の作成で既に作成した文書ファイルをコピーして書き換えたり、プログラム製作では似たようなロジックをコピーして流用したり、といった時にコピー部分に誤りが生じることがあります。

一般的には誤りの発生要因が同じものである場合は、重複フラグを立ててカウント対象外としますが、どのくらい重複が発生しているのか、なぜ重複が発生してしまったのか、といった原因追及をするには重複誤りも分析対象としてカウントする必要があります。